home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 639 < prev    next >
Internet Message Format  |  1996-08-06  |  2KB

  1. Path: news.iadfw.net!usenet
  2. From: Larry Weiss <lfw@iadfw.net>
  3. Newsgroups: comp.std.c
  4. Subject: Re: externsions and Standard C
  5. Date: Sat, 23 Mar 1996 16:31:20 -0600
  6. Organization: customer of Internet America
  7. Message-ID: <31547BB8.31D7@iadfw.net>
  8. References: <4gum82$14v4@info4.rus.uni-stuttgart.de> <MPLANET.31530e9djcoffin98993e@news.rmii.com> <31536199.219868914@nntp.ix.netcom.com> <315418FA.1508@iadfw.net> <1996Mar23.202452.14793@sq.com>
  9. NNTP-Posting-Host: dal20-22.ppp.iadfw.net
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.01 (Win16; I)
  14.  
  15. Mark Brader wrote:
  16. > lfw@iadfw.net writes:
  17. > > Mike Rubenstein wrote:
  18. > >  > You've missed a rather subtle point.  Such extensions are legal but
  19. > >  > they do not introduce integer types.  The standard defines the signed
  20. > >  > integer types as being signed char, short int, int, and long int (and
  21. > >  > similarly for unsigned integer types).
  22. > > It must be pretty subtle!
  23. > Not at all.
  24. > > Can you cite specific Clause references ...
  25. > It's in 6.1.2.5/3.1.2.5:
  26. > # There are four "signed integer types", designated as signed char,
  27. > # short int, int, and long int ...
  28. > It says four, not four or more.
  29. > # For each of the signed integer types, there is a corresponding
  30. > # (but different) "unsigned integer type".
  31. > It is true that size_t is specified by 6.3.3.4/3.3.3.4 as having an
  32. > "unsigned integral type" rather than "unsigned integer type", but the
  33. > draft Record of Reponse 2 confirms that these terms were not intended
  34. > to be distinguished.
  35. > Thus if x is of type size_t, printf ("%ul\n", (unsigned long) x); is
  36. > safe under the present standard.
  37. > --
  38.  
  39.  
  40. Let me try one more time to understand what makes an extension "legal"
  41. and what makes an extension "impossible".   
  42.  
  43.  Am I correct to understand that it is impossible for an implementation
  44. to define an extension that introduces new integer types?  (I'm pretty sure
  45. answer if "yes" for the above stated reasons).
  46.  
  47.  Am I correct to understand that is is possible for an implementation to
  48. define an extension that introduces a new type named  verylong  that
  49. behaves very much like, yet is not, an integer type?   If so, what clause
  50. of the Standard makes that extension possible?
  51.  
  52. (Let's get that much understood before I go off and study this some).
  53.